200.1 Introduction
The following conditions must be met before purchase orders can be input.
The following files must be defined:
Suppliers: define via AFO 241 ('Suppliers')
Currency codes: define via AFO 242 ('Exchange rate information')
Budgets: define via AFO 243 ('Budgets')
Destination codes: define via AFO 244 ('Destinations')
Print locations: define via AFO 245 ('Locations')
Country codes: define via AFO 246 (‘Country codes')
Requestors: optional, define via AFO 431 ('Borrower maintenance')
You also need to prepare for printing :
Define the parameters via AFO 271 ('Print parameters control')
Define the lay-out for the printouts via AFO 271
Please note
If your system uses cataloguing permissions, it is possible the message below appears in case you are not permitted to add, modify or delete orders, or receive them.
See the relevant help section of AFO 651 for more information.
200.2 Searching for an order
There are several ways of looking up an order. You need to do this, for example, to register the receipt of a purchase order. When you have selected the AFO, a search key screen will be displayed. If you know the order number it can be entered here preceded by a ‘G', e.g. G00000029.
The survey screen will then be displayed immediately. If you do not know the order number you first need to identify the bibliographic record.
200.3 Structure of an order
Starting points
In the acquisitions module it is assumed that an order can only be linked to one bibliographic record and sent to one vendor. More than one order, however, can be linked to a bibliographic record. For invoicing purposes the vendor can be changed in certain circumstances after the order has been sent. For instance, when an item ordered from vendor A is invoiced and supplied by vendor B; e.g. central library and branch library.
A purchase order can comprise several items (or volumes) which can be charged to one or more base funds. For this reason an order is made up of two sections, i.e.:
·
The general details such as the link to the bibliographic record, the vendor, the total number of copies and the total committed price
·
Details of one or more sub purchase orders. These include the base fund and the destination location
The material ordered in a sub purchase order is grouped by requester and base fund
This two section structure enables, for example, an order to have two items for location A on base fund X and three items for location B on base fund Y. This is an order for five items on the order slip or list for the vendor.
Bookkeeping model
The bookkeeping model that you choose before installing this module determines how the financial transactions are carried out in the order procedure. This model is determined by when the commitment balance and the bookkeeping balance are to be updated.
The commitment balance can be updated at three different times:
·
when an item is received (a).
·
when the price of an item is input (b).
·
when the invoice for the order is paid (c).
The bookkeeping balance can also be updated at three different times:
·
never - This means that the bookkeeping balance is never checked and only fund commitment amounts are taken into consideration (1).
·
when the price of an item is input and ‘empty' invoices (Invoices on which base funds and total prices are noted but individual orders are not.) are paid (2).
·
when invoices with purchase orders and credit notes are paid (3).
This means that nine bookkeeping models are theoretically possible. The table below shows which models can be used in the system.
|
Commitment / Bookkeeping |
1 |
2 |
3 |
|
a |
yes |
no |
no |
|
b |
no |
yes |
no |
|
c |
no |
no |
yes |
You therefore have a choice of three models:
|
Model |
Description |
|
‘fund commitment amount' model |
The bookkeeping is not checked. Only the commitment balance is checked after an item has been received. |
|
‘prices' model |
The commitment balance and the bookkeeping balance are amended when the price of an item is input. |
|
‘invoice' model |
The commitment balance and the bookkeeping balance are amended when the invoice for the purchase order is paid. |
The model chosen is determined by the agency's requirements. The fund commitment amount model is the simplest but the bookkeeping is not checked. The invoice model provides the most precise information and an exact check is made. This model does involve more work. The prices model is simpler to use but cannot, for example, process global discounts quoted on invoices.
Please note!
You must choose a bookkeeping model before the acquisitions module is installed. Contact the helpdesk before you set this parameter. Once you have input data you cannot change the model you have chosen. We recommend that you make this choice in consultation with your financial department and the helpdesk.
200.3.1 Types of purchase orders
The system uses four criteria for determining the type of order:
|
Criterion |
Code |
Description |
|
1 (acquisition) |
S |
Standard acquisition |
|
|
R |
Regularized - An item is purchased and usually paid for before being passed on to the acquisitions department for processing, unlike the other order types. |
|
|
G |
Donation - The code originates from the Dutch: Gift) |
|
|
Z |
On approval (the code originates from the Dutch: Zichtzending) |
|
2 (destination location) |
S |
Standard destination location |
|
|
E |
External services (i.e. the library orders items for a non-library location which may or may not be part of the agency) |
|
3 (material) |
S |
Standard type of material |
|
|
T |
Serial (the code originates from the Dutch: Tijdschrift) |
|
|
V |
Subsequent issue (the code originates from the Dutch: Vervolgwerk) |
|
4 (time) |
S |
Standard |
|
|
R |
Retro (use for purchase orders made before the acquisitions module was introduced) |
Note!
The code ‘S' (Standard) is used in all four criteria for the most common types of orders which do not fit into any of the other categories.
The codes in the table above can be combined to produce 48 order types.
Example
SSSS - standard purchase order
GSTS - donation of a serial
SESS - standard order for another agency
When the system is installed SSSS is defined as the default type. This can be changed with the help of a parameter in AFO 272 (‘Other parameters control').
200.3.2 The status of a purchase order
The status of an order reflects the steps which that order has already gone through in the order process. It is represented by a string of six characters. Each character indicates the status of the order in relation to a step in the order process.
.
Example
INNNNN input, nothing received, nothing invoiced, no first reminder, no second reminder, not cancelled
VTTNNN sent, totally received, totally invoiced, no first reminder, no second reminder, not cancelled
The status is displayed as six characters in the purchase order survey screen linked to a bibliographic record. The description is given in fields 10 to 15 in the survey screen of one order.
The various possibilities are shown in the table below.
|
Position |
Code |
Description |
Explanation |
|
1 |
I |
input |
The order has been input but not yet entered in a final print file. |
|
|
G |
locked |
The order has been locked because it has been entered in a final print file. The order is ready to be printed. (The code originates from the Dutch: Geblokkeerd.) |
|
|
V |
sent |
The order has been sent. The order slip has been printed. (The code originates from the Dutch: Verstuurd.) |
|
2 |
N |
nothing received |
No items have been received |
|
|
P |
partly received |
The order has been partly received. At least one of the items ordered has been received |
|
|
T |
totally received |
All the items or volumes ordered have been received |
|
3 |
N |
nothing invoiced |
No items have been invoiced |
|
|
P |
partly invoiced |
The order has been partly invoiced for at least one item or volume. |
|
|
T |
totally invoiced |
All the items ordered have been invoiced. |
|
4 |
N |
no reminder |
No first reminders have been sent. |
|
|
P |
partial first reminder |
A reminder has been sent for part of the order. A first reminder has been sent for at least one of the items or volumes ordered. This status will only occur in exceptional cases. |
|
|
T |
total first reminder |
A first reminder has been sent for all the items ordered but not received. |
|
5 |
N |
no second reminder |
No second reminders have been sent. |
|
|
P |
partial second reminder |
A second reminder has been sent for part of the order. A second reminder has been sent for at least one of the items or volumes ordered. This status will only occur in exceptional circumstances. |
|
|
T |
total second reminder |
A second reminder has been sent for all the items or volumes ordered but not received. |
|
6 |
N |
nothing cancelled |
Nothing has been cancelled. |
|
|
P |
partly cancelled |
Part of the order has been cancelled. At least one of the items ordered has been cancelled. |
|
|
T |
totally cancelled |
All of the items ordered but not received have been cancelled. |
The status in the overview of purchase orders linked to a bibliographic record is displayed as follows:
The status is displayed in the full screen of a purchase order as follows. The status is explained in fields 10 to 15.
The status of the order is displayed as follows in the OPAC:
·
not all of the items have been received. Status: on order.
·
the order has been cancelled. Status: order cancelled.
The screen also has an additional option ‘Order info'. If you select this option an overview giving detailed information about the purchase order will be displayed. This information is presented per sub purchase order if there are several sub purchase orders and you can easily browse from one to the other.
200.4 Invoice registration
This section contains essential information on using the AFO's: 223 (‘Register invoice numbers'); 231 (‘Register invoices') ; 232 (‘Overview invoices') ; 233 (‘Print financial transactions')
Invoices from vendors can be registered in the system. This registration is either based on the invoices (via AFO 231, when orders are linked to an invoice) or the individual purchase orders (for example via AFO 223 and AFO 211, when an order is linked to one or more invoices.
200.4.1 Functions of invoice registration
Keeping a detailed record of which orders an invoice has been received for.
Paying invoices. If your system uses the ‘invoice' model as bookkeeping model, paying an invoice will automatically have an effect on the base funds from which the order is paid, in particular the subtraction of the definitive amount to be paid on the invoice in the bookkeeping balance of the base funds and amending the commitment balance of the base funds.
Issuing credit notes to compensate for overcharging on invoices thereby adjusting the balance of the base fund in question.
Inputting pro-forma invoices (invoices for items yet to be received) or, in other words, ‘advance' payment
200.4.2 Invoice registration in the context of base funds control
There are three strategies for registering invoices (if we disregard non-registration of invoices):
·
The global registration of invoices whereby a note is made of which orders the invoice is for (with a view to linking them correctly to the original fund commitment amounts. The definitive price of the individual items ordered, however, is not taken into account. In this model only the total amount of an invoice is taken into account, and the invoice is divided manually between the base funds in question.
·
The detailed registration of all prices noted on the invoices (the unit price of the orders quoted on the invoice) so that the system itself can calculate the total prices on the invoice and where necessary split the amounts between the different base funds (including dividing up the global expenses between these base funds).
·
The global registration of invoices without linking them to individual purchase orders.
The second method is to be preferred when an invoice is for orders which are charged to different base funds. Otherwise the total amounts per base fund have to be calculated manually. The disadvantage of this method, however, is that registering the correct unit prices on the invoice is relatively labour intensive unless the correct price was already known when the order was input. (The latter is often the case, for example, with items on approval.)
Options 1 and 2 described above can be used interchangeably.
As the definitive unit prices are often not known when an order is made, it is more efficient, if it is possible, only to order items charged to the same base fund on one invoice. The first method then works well as it is sufficient to specify the total amount of the invoice to be deducted from the appropriate base fund
Which model is chosen is therefore closely linked to the way the base funds are structured. Agencies that work with extremely generous base funds or base funds linked to vendors often opt for global registration.
The advantage of detailed registration of invoices is of course that you can then have extremely precise base funds which can be monitored in detail.
200.4.3 Invoice registration based on the purchase order
An invoice can be linked to a purchase order in two ways in the system, i.e.:
·
on the basis of the invoice (via AFO 231).
·
on the basis of the purchase order (via AFO 223 and
AFO 221 for example).
Generally speaking there are three reasons for choosing to register invoices on the survey screen of a purchase order:
·
Invoices are registered when items are received.
·
External order numbers (which can group together several orders) are not used – see the section on AFO 215 (‘External order numbers control') for an explanation of the concept ‘external order number'.
· If the most efficient way of identifying the purchase orders on the invoice is by title (or one of the other usual indexes) and not by order number, for example because the latter does not appear on the invoice.
200.4.4 Invoice registration based on the invoice
This method starts with an empty invoice and links the purchase orders to this invoice, or rather, notes them on this invoice.
In practice, this method is used when orders can be identified by the order number or an external order number (possibly a global number for several orders).
200.4.5 Differences
The differences between these two methods of registering invoices can be summarised as follows:
If registration is based on the order, all items can be noted on the invoice regardless of whether they have been received or not. An invoice for items that have not yet been received is called a pro forma invoice.
If registration is based on the invoice, items can only be noted on the invoice that have been received and have not previously been noted on an invoice. Do not forget that all of the items must be noted.
200.5 Removing an order from the file through deletion, cancellation or archiving
There are various possible reasons for removing an order from the file. Each of these reasons have their own procedure. The system distinguishes the following reasons:
During order entry a mistake has been made and therefor the order must be deleted.
To delete an order you must delete all partial orders. After deleting the last partial order the order itself is deleted automatically. An order can be deleted as long as the status is ‘Input'.
If the status is ‘Locked' or ‘Sent' it is no longer possible to just delete the order. There are two possibilities in this case:
There has been correspondence with the supplier (or requestor). In this case you need to cancel the order. Read the section on cancellations for more information.
There has been no correspondence with the supplier (or requestor). In this case the order, if not yet invoiced, can be reversed and then deleted.
The order can be cancelled for one of the following reasons:
The supplier has informed the library the ordered document can not be supplied.
The library cancels the order for internal reasons.
Essential in this case is that notices must be sent because of this cancellation ánd that the order will remain on file. You must use the cancellation mechanism.
The order is old and completed but the details must be retained on the system. In this case you need to archive the order (within or outside of Vubis Smart).
With this option it is possible to move ‘old' orders to a file outside the main database or even outside the system (e.g. on CD or DVD).
200.6 Claims and cancellations
Vubis Smart automatically keeps track of claim and cancellation dates. In case an order has not been received by a certain date, the system will automatically generate a first or second reminder or a cancellation.
However, there are situations where it is useful or necessary to influence this process manually. The automatic process can be influenced as follows:
200.6.1 Amending the claim and cancellation dates
When a purchase order is input the system sets the reminder and cancellation limits according to the defaults. These defaults are defined at two levels:
Level 1:
Limits input at the vendor level. These limits function as defaults when a purchase order is input.
Level 2:
Limits input in the country codes control. These limits function as defaults for level 1, i.e. when a vendor is input in the vendor file.
You can override these defaults by manually changing the dates set by the system.
Some examples for a useful change of claim and cancellation dates:
·
The vendor has notified you that item x can only be supplied after date y; hence there is no point in sending the vendor a reminder before that date.
·
The default limit for reminder 1 is 30 days for vendor x. You know that the item you have ordered from vendor x will have to be ordered abroad. In your estimation there is therefore no point in sending a first reminder until 90 days after the item was ordered.
· Owing to a message received from the vendor, you want to prevent an item being cancelled. This can be done by amending the cancellation date of the purchase order. In this way you can prevent items being cancelled.
200.6.2 Amending claim and cancellation numbers
The system always sends reminders / cancellations for all items that have not yet been received (but not for items that have been deleted or cancelled). To do this the system uses a reminder / cancellation notice which is generated automatically. You can change this notice manually. (This option is comparable to changing the total purchase order when inputting a purchase order.)
As implied above, it is possible to send a cancellation, first reminder or second reminder more than once (although this is unlikely with reminders). This applies to the different parts of a purchase order; it is a direct consequence of the possibility to set the dates for reminders and cancellations at the level of the individual items.
Example
Ten copies have been ordered of an item. You have received notification from the vendor that only two copies can be supplied quickly and that the other eight will be supplied later. The two copies will have the reminder date x and the other eight will have the reminder date y. Thus it is possible in this case to send two reminders.
200.6.3 Adding a message to claims and cancellations
It is possible to add a message to every reminder and cancellation. Such a message can include all kinds of information. (See the examples below.)
Examples
With reference to our telephone conversation of 9 March.
With reference to your letter, 92/00055
200.6.4 Do not send cancellation
The system enables you to cancel a purchase order without sending the vendor a cancellation notice. This is relevant in the following situation: the vendor has informed you that item x cannot be supplied. The purchase order must therefore be cancelled but it is not necessary to send a cancellation notice as it was the vendor who brought the matter to your attention.
200.6.5 Omit a reminder
If you wish you can omit one or both reminders (i.e. not send them). To do this you move forward the dates for the next reminder and/or cancellation.
Examples
Reminder 1 = 9 March 96
Reminder 2 = 9 May 96
Cancellation = 9 August 96
On 7 March you enter the cancellation date as 8 March. This will have the effect (assuming that a print file of cancellations is generated and printed on 9 March) that reminder 1 and reminder 2 will be never be sent (because the cancellation will already have been sent).
To change the dates of reminder 1, reminder 2 and cancellation, select the field Reminder 1, Reminder 2 or Cancellation in the purchase order survey screen and then select the option ‘Select number'. The procedure you then follow is determined by whether an amendment has previously been made regarding reminder 1, reminder 2 or cancellation respectively.
200.6.6 There has been no previous action
If an amendment has not previously been made regarding reminder 1, reminder 2 or cancellation, an input screen will be displayed. Enter here by how many days the date in question must be changed.
Enter the number of days. This can be either a positive or a negative number. A positive number means that the date of the reminder will be later, a negative number means that it will be earlier. The number of days entered is relative to the date in the system at that moment. Another alternative is to enter a – (minus sign). The date is then set at today's date.
If the date for Reminder 1 is changed the dates for Reminder 2 and the Cancellation date will also be changed. If the date for Reminder 2 is changed the Cancellation date will also be changed.
200.7 Standing orders (parent/child)
Multiple bibliographic records (“child” items) may be added to a single order/request (“parent” item) in order to handle memberships, serial title splits and changes, monographic series, standing orders, and so on. Staff add this information from Ordering, and can update it in Receiving or Ordering. The order number associated with a child order is the same as that of the parent – only the bib record will be different. Staff may receive and claim copies of the child items separately, and may invoice them separately too.
Vubis allows you to add one or more child
items to a parent item's order. This provides the convenience of a single order (and single set of budget encumbrances) yet still enables you to receive, claim, and invoice items separately or together as you wish.
Child records do not have budget accounting done on them. All budget accounting is done on the budgets in the original parent order record.
Types of Child Items
There are two types of child items: title split/change items and monographic series
items. The type is determined by which option you use to create the item:
·
TITLE SPLIT/CHANGE This item is a child bibliographic record describing the title a parent serial item has changed to or been split into, or possibly the title that comes as part of a membership.
·
SERIES ENTRY TITLE This monographic series item is a child bibliographic record describing one of the titles encompassed by a parent item.
Number of Levels
The number of levels of parent-child division allowed differs.
·
Title split/change: Child items can, themselves, be the parents of further title/split change or monographic series items. In some cases, however, suppliers might require a brand new order, for example for a new serial created by a title split.
·
Monographic series: Child items cannot be further divided.
Different statuses are assigned and displayed, and could be used in library-designed reports.
Order printing
Child records are skipped when generating orders (via AFO 251/252/253).
Receiving
Any receipts added to a child record are added to both the parent and the child record.
On the receipt screen of the main parent record, if a receipt line was generated by a child record, the child's title will display in the Child title column. Cancellation or undo of receipt information for child titles is not allowed from the parent record. A receipt or invoice generated by a child record must be cancelled from the child record.
Invoicing
Any invoicing added to a child record is also added into the main parent record.
Invoicing of child records is done by first accessing the child record (i.e. by selecting the global registration icon from the Order detail screen, by selecting the Invoice status line from the Order detail screen, using AFOs 223/224/225). Child records cannot be added to an invoice through AFO 231/232.
When a child is invoiced, a corresponding receipt line will be created/updated in the parent record. This allows you to see the invoicing done on all of the child records from the parent order.
Claiming
Claims are generated at the parent level.
Child records are skipped (1st and 2nd claim dates and cancellation date fields are ignored). If necessary, child records can be claimed manually from the receiving screen.
Archiving
Archiving (in AFO 211 – Order summary screen and AFO 261x) will skip parent and child records – these records will not be archived as their receipt and invoicing process is ongoing.
Copy order logic
If you attempt to copy an order (parent or child) to another bib, the system first checks to make sure that the current order number does not already exist on the other bibliographic record. If it does, the copy is not carried out.
SAP export
Child records will be skipped. Receipts and invoice information from parent records will be exported.
Deleting child records
The child must be deleted before the parent can be deleted. Use the delete current child option from the Parent/Child icon to delete a child. Please note: you must remove all receipt and invoicing information from the child before it can be deleted.
Sample Order
This example is a complex membership order which includes serials, a monographic series, and a monograph.
Zoological Society Membership (annual institutional membership; includes the following child items, some of which are themselves parent items):
• Zoological Journal (title split/change child: a serial)
• Zoo News (title split/change child: a serial, splits into two child serials early in the year)
• North American Zoo News (title split/change child: a title-split serial)
• International Zoo News (title split/change child: a title-split serial, changes title late in the year)
• World Zoological Newsletter (title split/change child: a title-change serial)
• Zoological Dictionary (title split/change child: a monograph)
• Animal Management Series (title split/change child: a monographic series)
1) Reptile Management (monographic series child)
2) Big Cat Management (monographic series child)
3) (further monographic series children).